IBIS Macromodel Task Group Meeting date: 18 August 2009 Members (asterisk for those attending): Adge Hawes, IBM * Ambrish Varma, Cadence Design Systems * Anders Ekholm, Ericsson * Arpad Muranyi, Mentor Graphics Corp. Barry Katz, SiSoft * Bob Ross, Teraspeed Consulting Group Brad Brim, Sigrity Brad Griffin, Cadence Design Systems Chris McGrath, Synopsys David Banas, Xilinx Deepak Ramaswany, Ansoft Donald Telian, consultant Doug White, Cisco Systems * Eckhard Lenski, Nokia-Siemens Networks Essaid Bensoudane, ST Microelectronics Fangyi Rao, Agilent Ganesh Narayanaswamy, ST Micro Gang Kang, Sigrity Hemant Shah, Cadence Design Systems Ian Dodd, consultant Jerry Chuang, Xilinx Joe Abler, IBM * John Angulo, Mentor Graphics John Shields, Mentor Graphics Ken Willis, Cadence Design Systems Kumar Keshavan, Sigrity Lance Wang, Cadence Design Systems Luis Boluna, Cisco Systems * Michael Mirmak, Intel Corp. * Mike LaBonte, Cisco Systems Mike Steinberger, SiSoft Mustansir Fanaswalla, Xilinx Patrick O'Halloran, Tiburon Design Automation Paul Fernando, NCSU Pavani Jella, TI Radek Biernacki, Agilent (EESof) * Randy Wolff, Micron Technology Ray Komow, Cadence Design Systems Richard Mellitz, Intel Richard Ward, Texas Instruments Samuel Mertens, Ansoft Sam Chitwood, Sigrity Sanjeev Gupta, Agilent Shangli Wu, Cadence Design Systems Sid Singh, Extreme Networks Stephen Scearce, Cisco Systems Steve Pytel, Ansoft Syed Huq, Cisco Systems Syed Sadeghi, ST Micro Ted Mido, Synopsys Terry Jernberg, Cadence Design Systems * Todd Westerhoff, SiSoft Vladimir Dmitriev-Zdorov Vikas Gupta, Xilinx Vuk Borich, Agilent * Walter Katz, SiSoft Zhen Mu, Cadence Design Systems ------------------------------------------------------------------------ Opens: Mike L: It may help for the roll call to be an item on the agenda template - Arpad: It will be added Arpad: We might want to discuss the IBIS-ISS wish list Bob: What is happening with the AMI specification? -------------------------- Call for patent disclosure: - No one declared a patent. ------------- Review of ARs: - Arpad send updated IBIS-ISS presentation to Walter - TBD - Mike change web page to make items easily linkable - TBD - Arpad write a BIRD to clarify time period accuracy requirements - TBD - Todd: Write IBIS s-param BIRD - No update - Arpad: Write parameter passing syntax proposal (BIRD draft) for *-AMS models in IBIS that is consistent with the parameter passing syntax of the AMI models - TBD - TBD: Propose a parameter passing syntax for the SPICE - [External ...] also? - TBD - Arpad: Review the documentation (annotation) in the macro libraries. - Deferred until a demand arises or we have nothing else to do ------------- New Discussion: Bob: What is happening with the AMI specification? - Michael M: We are in a holding pattern until this discussion is finished - Bob: We are in a confused state right now - Arpad: Is there anything new from the parser developer? - Bob: We might have to close down AMI checking entirely - Walter: I can start a discussion on this today - There are 3 proposals on the table - Ambrish: Would the change be for 5.1 or 5.0? - Bob: We are only considering 5.0 now - Arpad: The parser developer is asking about 5.0 - Even if we change the spec for 5.1 we still need to answer the developer now - Bob: We will probably have to leave out table checking - Arpad: Kumar emailed a presentation to Arpad - It responds to Walter's presentation on his AMI proposal - Kumar may not be able to attend for discussion today - This will be put on the agenda for the next meeting - Ambrish: I have some points to make from my email Walter showed Ambrish's text document and email: - Ambrish: "Default" is used to let EDA tools know of reserved parameters - Instead of this we could have "Value" as the keyword - Default was to fill in for things that are not in the AMI file - That should solve the parser developer's problems - It should be the same whether Reserved or Model Specific - Walter: This is more confusing now - Why do we have Format? - Ambrish: Eliminating that would be a big change - Walter: Our parser discards it - Arpad: Could we have an explanation for Format? - Walter showed the AMI BIRD - Walter: It doesn't make sense for Type String to have Format Range, for example - Nothing in AMI has more than one value - Arpad: How about taps? - Walter: Each tap can have only one value - They might be selected from a range - All we need is (Range ...) etc. to introduce a range - Walter showed an example using Format as given by: spec: (Format )(Default) Ambrish: (Format )(Value )(Default) Walter: (Range 0-12)(Default 0) - Another example: Ambrish: (Ignore_Bits (Usage Info)(Type Integer)(Default 21) Walter: (Ignore_Bits (Usage Info)(Type Integer)(Value 21) - Another example: Ambrish: (GetWave_Exists (Usage Info)(Type Boolean)(Format Text)(Value True)) Walter: (GetWave_Exists (Usage Info)(Type Boolean)(Value True)) - Walter: The spec requires Default on everything - But it should not require that - We added Default because anything could be a default - Arpad: The user can't set the Default? - Ambrish: it can't be changed - Walter: What does Default mean when the parameter is in the file? - Ambrish: Default is only for user parameters - It can be removed from required parameters - Bob: At this point we are checking syntax, not if it makes sense - We could just keep Format and ignore it - Todd: We could get models that cause problems - Walter: We should have one spec that is not confusing - Ambrish: Format can not be passed into the DLL - There is an example on page 186 - Arpad showed AMI spec page 186 - Todd: The example violates the required tree structure - Mike: The .AMI file only has instructions on how to pass to the DLL - Ambrish: The model maker decides what "taps" can be, for example - Bob: Would removing Format impact anyone? - Ambrish: No - Bob: Does anyone use it? - No one knew of any case - Arpad: Not SiSoft, Mentor - Ambrish: Probably not Cadence - Michael M: It would be a mistake to distribute a parser if we are changing whole keywords - Walter: Agree - Bob: SiSoft is already writing non-compliant code - Walter: We comply except the input to Tx_GetWave - Michael M: It would be good to have two working example models - Arpad: The spec will have to change even if we agree on something today - The spec still has conflicts - Will this change be documented as a BIRD? - If so, can we ask the parser developer to make the change ahead of the BIRD? - Bob: We need a fully vetted BIRD - Michael M: Nothing should be implemented in the parser until we approve something - We should avoid speculative work - Arpad: Then it waits until 5.1 - Michael M: Unless there is something that really won't change - Mike L: We could check parentheses balancing and keyword char set - Don't check the actual keywords - Walter: Also ignore tree structure - Don't check GetWave_Exists or the table - Maybe could parse Jitter - Maybe could check that Range is followed by 3 numbers - Bob: Then Default would be optional - We are in a mess - Todd: Format, Range etc. in AMI doesn't violate the DLL syntax - Some DLLs expect Format and some do - Ambrish and Walter said it should never be passed - Bob: Which DLLs require Format? - Michael M: Once a requirement is in a spec, we have painted ourselves into a corner - Todd: The .AMI purpose is to limit the range of values passed to the DLL - Ambrish: Models that accept Format are wrong - Walter: We need an example with a .AMI file to make it clear - Todd: SiSoft and Cadence agree Format is wrong - Walter: So anyone passing that is wrong - Bob: Is the .AMI read by the DLL? - Ambrish: No - Michael M: The parser only checks .AMI against the spec, doesn't care about the DLL - Arpad: Why are we talking about what is passed to the DLL if that is separate? - Todd: Why not get rid of Format? - Ambrish: Should Type usage go too? - Walter: if Format is always followed by another keyword, why not keep just that? - Bob: No document specifies that Range can be used as a keyword - Arpad: This discussion is moot until we have a BIRD - Bob: If people are sending Format to DLLs we might have to support that - Ambrish: If we remove Default and say Value that would do it - Bob: We could make Default optional - Walter: My last email solves this - Arpad: Can we tell the parser developer to proceed? - Ambrish: For a required parameter using Value instead of Default will work - Walter: (Default is the default when a list is given - It is not what the DLL assumes Michael M: We should not have a parser that checks these things - Not until we have a spec change - One of the examples is missing a parentheses - Arpad: We should check only parentheses and spelling of known keywords - No other syntax rules or logic should be checked - Walter: A misspelled word looks like a leaf - Some params have to be Input but are Info now - Michael M: The DLL flow makes the parser issue less significant - Todd: Did we get here only because of Format and Default? - Michael M: Yes, the parser ran into trouble with those - Even after the paren was put in it was still wrong - We could not figure out if Format was required - Todd: What is the problem with Default? - Bob: It was flagged as an error in GetWave - Ambrish: It is used in two places - Michael M: We got 4 errors - Illegal Format for Init ... - Illegal Format for GetWave ... - Parameter Format is mandatory ... - Parameter GetWave_Exists is mandatory ... - Todd: I can fix parentheses problem in toolkit - Ambrish: There is a GetWave_Exists example on page 150 - Arpad: What to we tell the parser developer? - Mike L: It should check the minimum - better to pass a bad model than to fail a good one - Arpad: Shall we have only parentheses and spelling checked? - We agreed on this AR: Michael M send info about parser problems found Next meeting: 1 Sep 2009 12:00pm PT -------- IBIS Interconnect SPICE Wish List: 1) Simulator directives